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Abstract. This paper addresses the procedure to build a spatial reference 
framework for storing, managing, browsing and analyzing survey camp da- 
ta, collected annually by Geodesy and Geomatics Engineering (GGE) stu- 
dents at the University of New Brunswick. Appropriate feature coding and 
modeling practices have been applied. ESRI ArcGIS has been utilized, to 
implement the spatial framework for modeling and management of past 
and future measurements. In order to make the spatial framework easily 
accessible, a Web-GIS application has been developed using ArcGIS Server 
on the server side and ArcGIS J avaScriptAPI on the client side. 
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1. Introduction 

M any organizations that manage geospatial information use Gl S data mod- 
el ling techniques to develop a database of their holdings. At a very high lev- 
el, this often involves using a GIS to: (a) create a data model of their geo- 
spatial holdings; (b) build a geodatabase based on this model, and finally 
(c) populate the database. For some applications such as the student trai n- 
ing survey camp, the GIS data model, the populated spatial database and 
the applications built on this database can be viewed as a geospatial refer- 
ence framework. This is because the data model, database, and applications 
and documents bui It on this database etc. provide students with a reference 
for both: (i) describing the survey work that they need to do (i .e. the topo- 
graphic features they need to survey, the procedures that they need to fol- 
low when collecting and processing their data, etc.); and (ii) validating their 
survey work. 

Several approaches have been used in different fields to create spatial data- 
bases using GIS data modeling techniques, including: archeological [Ten- 
nant, 2007], infrastructural [Vemulapally, 2010], environmental [Smith 
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and Devine, 2006], topographical [Zainal and Parker, 2004] and temporal- 
spatial [Wenzhong and Minwen, 2000]. In the above mentioned studies, 
several factors were considered during the data modelling phase such as: 
output data products and input data sources (spatial representation, accu- 
racy, etc.). I n the case of this research project, the purpose of our data mod- 
elling exercise was to create a framework (data model, GIS repository, ap- 
plications and documentation built on the repository) for managing, storing 
and visualizing the student surveyed topographic data. 



2. Background 

Each year, GGE students conduct a topographic survey of UNB campus. 
Students work in groups and each group is assigned a specific area of UNB 
Campus. Each survey area typically contains several types of features such 
as buildings, sidewalks, streets, parking lots, elevation data as contours, 
green areas, trees, lamp posts, etc. Each group is responsible for creating a 
digital CAD file and a topographic map of their survey area and these two 
products are typically created using CAD software. Figure 1 shows an ex- 
ample of survey topographic features for a section of UNB campus. 

I n general, the student's survey data tends to accurately depict the location 
of features on UNB campus - that is, the surveyed data meets camp specifi- 
cations. However, in examining the student created CAD datasets in GIS 
software, many issues were identified. Two of these are: (a) no consistent 
feature codi ng system; for example, one group may code buildings as BLDG 
whereas another group may use BL and (b) point and polygon type features 
were encoded as polylines. Refer to Section 3.1for more examples of prob- 
lems with the CAD datasets. 

The objective of this project was to create a geospatial reference framework 
from the student surveyed topographic data. The information products re- 
sulting from this project are a GIS repository, documentation and a web 
application. The web application allows students to view the information in 
the repository. The documentation will describe standards, procedures, 
quality control mechanisms to ensure their data is suitable for input into 
the Gl S repository of university campus. Figure 2 shows an example of our 
expected results - that is, how UNB campus should appear after surveyed 
data has been appropriately collected, processed and stored in a GIS reposi- 
tory. 
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Figure 2. Example of our expected results - that is, how UNB campus should 
appear after surveyed data has been appropriately collected, processed and stored 
in aGIS. 
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3. Solution and Workflow 

This section describes the approach that was used to create the geospatial 
reference framework. 

I n order to create the framework, we performed the foil owing steps: 

1 Created an initial database for UNB campus using existing survey 
camp data and identified problems with the data. 

2. Identified criteria for the survey data to be imported into a spatial 
database (ArcGI S Geodatabase) . 

3. Created an ArcGI S Geodatabase for storing UNB campus data. 

4. Populated the ArcGI S Geodatabase accordi ng to above design. 

3.1 Create an initial database and identify inconsistencies in 
survey data 

Inthisstep, weimported the surveyed topographic data (i.e. CAD files) into 
a Gl S. We then examined the data and identified which features types were 
included surveyed data (not all topographic features on UNB campus were 
surveyed, e.g. signs) and any inconsistencies in the data. Examples of the 
inconsistencies in the data are: 

• No consistent feature coding system; For example, one group may 
code bui I di ngs as BLDG whereas another group may use BL . 

• Poi nt and polygon type features were encoded as polyl i nes. 

• Different features were often incorrectly coded during the survey 
camps. Figure 3 shows an example of street centerlines coded as 
buildings. 

• Shared geometries between different features are not defined. For 
example, edges (or boundaries) between buildings on the university 
campus and their parking lots are not defined as being shared. Fig- 
ure 4 shows an example in which the shared boundary between a 
building and a parking lot is coded as building. 

• Some areal features such as parking lots and green areas were not 
surveyed as enclosed features. That is, there is a gap between the 
starting and ending points of these features. 

• I nconsistent survey of treed areas - some groups delineated treed 
areas whereas other groups did not. 

• Inconsistent spatial location of features - different surveys often 
show the same feature in different spatial location. 
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Figure 4. Exampleof building and parking lot features with shared boundaries. 
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Fromthisstep, we made several observations including: 

• Manual editing is required to clean surveyed data (eg. ensure all 
features are correctly coded) and to correct spatial representation 
(eg. represent features such as buildings, parking lots and green 
areas to represent them as polygons i nstead of I i nes. etc.) . 

• Need standards for students to follow (eg. common coding scheme 
for features (buildings- BD, roads- RD), etc.). 

• Difficult to determine which student survey data most accurately 
depicts location of UNB features. Students periodically survey the 
same area. For example, the engineering building was surveyed in 
both 2008 and 2010. Unless we actually conduct benchmark sur- 
veys, it is difficult to determine which dataset (2008 vs 2010) most 
accurately depi cts I ocati on of the engi neeri ng bui I di ng. 

• Validated our belief that a Geospatial reference framework of the 
university campus (GIS data repository, web application) would be 
helpful for future survey camps for several reasons. Two of these 
are: (a) useful in describing survey work that they need to do and (b) 
hel p students val i date thei r results. 

• All surveyed data is in New Brunswick double stereographic projec- 
tion (NAD83 CSRS). 

3.2 Identify requirements for the survey data 

From the above (eg. features in CAD datasets, inconsistencies in data), sur- 
vey camp requirements and our knowledge of UNB campus, we identified 
several requirements for the survey data, including: 

• Features to be surveyed is constant and consistent for all areas on 
university campus -for example, all survey groups will survey treed 
areas as treed areas as oppose to one group surveyi ng treed area as a 
treed area and another group surveying treed area as a green space. 

• Common coding system will be used to define features - for exam- 
ple, all buildings coded asBL 

• All features will have a consistent spatial representation (e.g. all 
parking lots will be surveyed as an enclosed feature as oppose to 
some bei ng surveyed as enclosed feature and others not). 

• Shared geometri es are i ndi cated i n the surveyed data 

• Al I features have the same coordi nate system. 

Note identifying such requirements is a necessary perquisite to database 
design because they help us to define the characteristics (attributes, shared 
geometry, etc.) of the i nput survey camp data. 
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3.3 Geodatabase Design 

This section describes the steps that we followed to design a geodatase for 
student surveyed topographic data. As described in Designing Geodata- 
bases [Arctur and Zeinel, 2004], there are 10 steps involved in designing a 
geodatabase. A modified version of these steps is listed in Table2. As shown 
in Table2, these steps can be grouped into 3 phases, namely: (a) conceptual 
design; (b) logical design and (c) physical design. 



Table 2. 10 steps i n Desi gni ng a Geodatabase [Arctur and Zei nel , 2004] 



Steps 


Phase 


1 Identify the information products that will be 
produced by the created framework 

2. Identify the key thematic layers 

3. Specify the scale range and spatial representati- 
on for each themati c 1 ayers of the base map 

4. Group representati ons i nto datasets 


Conceptual 
Design 


5. Def i ne the tabul ar database structure and beha- 
vi or for descri pti ve attri butes 

6. Def i ne the spati al properti es of your datasets 

7. Propose a geodatabase desi gn 


Logical Design 


8. Implement, prototype, reviews and refine the 
design 

9. Design work flows for building and maintaining 
each layer 

10. Document your design using appropriate me- 
thods 


Physical De- 
sign 



These steps are now briefly described below along with the results of im- 
plementing a Geodatabase design for this project. 

3.3.1. Identify the information products 

Based on the survey camp requi rements and our knowl edge of Gl S database 
creati on, the f ol I owi ng i nf ormati on products were i dentif i ed: 

• A GIS repository for UNB Campus which contains survey camp data. 
The repository contains best survey camp data in terms of the year of 
data collection and data completeness. 

• AWeb-GIS application which shows the information in the GIS reposi- 
tory. 
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• Documentation that describes standards, procedures and quality con- 
trol mechanisms to ensure their data is suitable for input into the Gl S 
repository of university campus. 

3.3.2. Identify the key thematic layers 

Key themati c I ayers were i dentifi ed by exami ni ng both exi sti ng survey camp 
data and survey camp requirements. These layers and their spatial specifi- 
cations are listed in Table 3. 



Table 3. Key Thematic Layers and their spatial specification 



Key Features 


Spatial Represen- 
tation 


Spatial Reference 


Building 


Polygon 


NAD83/New Brunswick Double Stereo-Graphic 


Parking Lot 


Polygon 


NAD83/New Brunswick Double Stereo-Graphic 


Green Areas 


Polygon 


NAD83/New Brunswick Double Stereo-Graphic 


Contours 


Line 


NAD83/New Brunswick Double Stereo-Graphic 


Street 


Line 


NAD83/New Brunswick Double Stereo-Graphic 


Side walk 


Line 


NAD83/New Brunswick Double Stereo-Graphic 


Tree 


Point 


NAD83/New Brunswick Double Stereo-Graphic 


Utilities 


Point 


NAD83/New Brunswick Double Stereo-Graphic 



Existing survey camp data was examined to determine what feature types 
are in surveyed area and what spatial representation is best suited for re- 
presenti ng these features. 



3.3.3. Specify the scale range and spatial representation 

At thi s ti me, seal e ranges were not consi dered for this proj ect 

3.3.4. Group representations into ESRI feature datasets 

Two approaches that could be used to group survey camp data into feature 
datasets are: (a) group data according to year (e.g. all 2011 survey data is in 
one dataset) or (b) group features according to feature types (e.g. all buil- 
di ngs from different years are i n a feature dataset). For this project, we used 
the later approach. 

3.3.5. Define the tabular database structure and behavior 

I n this step, thefeature coding system for each feature is defined (see Table 
3). 



26th International Cartographic Conference, August 25 - 30, 2013, 

Dresden, Germany 



Table3. Attri bute system for each identified features i n survey camp 



Feature Classes 


Feature Code Field 


Data Type 


Length 


Building 


BD 


String 


10 


Parking Lot 


PL 


String 


10 


Green Areas 


GA 


String 


10 


Contours 


CT 


String 


10 


Street 


ST 


String 


10 


Side walk 


SW 


String 


10 


Tree 


TR 


String 


10 


Utilities 


UT 


String 


10 



At this time, we did not implement any validation rules associated with the 
individual feature classes (eg. buildings must be greater that a specific area, 
trees cannot be inside a building, etc.). 

3.3.6. Define the spatial properties of the datasets 

Since survey camp data is collected in New Brunswick Double Stereogra- 
phic projection (NAD83 CSRS) projection, this spatial reference system was 
used for all feature datasets. 

3.3.7. Propose a geodatabase design 

A geodatabase for UNB campus was proposed to several stakeholders 
associated with his project. 

3.3.8 Implement, Prototype Geodatabase Design 

F i nal desi gn of the geodatabase consi sts of feature datasets for each type of 
campus feature. Depending on spatial representation of a particular feature, 
thefeaturedataset may contain either a point, line or polygon feature class. 
Fi gure 5 shows the f i nal design and structure of the geodatabase. 

B LJ Camp Repository 
S ft Building: 
E ft Contours 
El ft GreenAreas 
El ft ParkingLots 
El ft SideWalk 
El ft Streets 
El ft Trees 
El ft Utilities 

Figure 5. Proposed Geodatabase Design 
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3.3.9 Design work flows for building and maintaining each layer 

Atthistime, thisstep has not been completed. 

3.3.10 Document your design using appropriate methods 

Atthistime, thisstep has not been completed. 

3.4. Populate the geodatabase 

We examined student surveys (i.e. CAD datasets) and selected the 
dataset for each area of U N B campus - recal I that U N B campus was 
divided into survey areas and each group surveyed one area - that 
appeared to most closely meet survey camp requirements. The fea- 
tures in these datasets were then added to the appropriate feature 
class in the geodatabase. These names of these feature classes have 
thesuffix"BaseMap". Figure 6 shows the populated geodatabase. 
In the future, we will populate the database with CAD files from pre- 
vious years. This means for example, that the buildings feature da- 
taset will also contain feature classes Buildings_2007, Build- 
ings_2008, etc. 



P l3 Camp Repository 

□ 15 Buildings 

I Ml Buildings_BaseMap 
El ^5 Contours 

Contours_BaseMap_up 
B 15 Green Areas 

O) GreanAreas_BaseMap ' 

□ 15 ParkingLots 

O) ParkingLots_BaseMap 

□ 15 SideWalk 

EE) SideWalk_BaseMap 

□ 15 Streets 

EE) Streets_BaseMap 
B 15 Trees 

1*^1 Tree_BaseMap 
B 15 Utilities 

L-D Utilities_BaseMap 



Figure 6. Populated geodatabase. 
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4. GIS Modeling and Geodatabase Maintenance 

ArcGIS model -builder and python scripts will be used to: (a) validate future 
survey camp data; and (b) import this data into the geodatabase. We will 
validate the survey data to ensure that it conforms to the database model 
developed above. The validation procedure will consist of ArcGIS models 
that: (a) perform several checks on the geometry and attributes of the fea- 
ture classes and (b) report on its results. Such checks will allow us to verify 
that: (a) all features are assigned a valid code; (b) areal features are en- 
closed, etc. If the errors/ inconsistencies are reported, we may request that 
survey groups address these problems and resubmit CAD files. 



5. Web-GIS Application Development 

Thissection describes the development of the Web-GIS prototype for acces- 
sing and representing the survey camp framework. The prototype system is 
set up based on ArcGI S server as Gl S server and ArcGI S J avaScri pt API as 
the web programming language. The web service is built on the UNB cam- 
pus base map created from survey camp topographic data. The base map is 
published as an interactive map service. The map service provides a series 
of functionalities in respect to the framework design and characteristics. 
GIS functionalities are served by the ArcGIS server and ArcGISJ avaScript 
API requests the services based on the ArcGI S REST API . 

The most important part in developing the prototype system in this project 
was to design the client side environment. In designing the web application, 
we have tried to provide appropriate visualizing functionalities along with 
particular useful query tasks. All these mapping and GIS techniques will 
help the user to understand and explore the framework through a web ser- 
vi ce even wi thout havi ng any sped f i c ski 1 1 s on desktop Gl S appl i cati ons. 

I n order to devel op an i nteracti ve web servi ce, a I i st of base map I ayers were 
created. Users can better understand what and which are the main features 
to be considered during a survey camp operation. Additionally, they can 
realize the most appropriate symbols and data types for the different fea- 
tures collected during a survey camp operation. By exploring the layers, the 
user can also figure out what areas of campus might have lack of data. This 
is a val uabl e i nput for panni ng the future survey camps. 

Figure 7 shows the web service interface. I n this snapshot, buildings; par- 
king lots and streets have been selected as visible map layers. Each of these 
selected layers has different data type such as polygon or line data types. 
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Camp Feature Layers: □ SideWalk Street HTrees Utilities 0Buildings 0Parkiiig-Lots HContours HGreenAreas 




Figure 7. Example of selected layers of bas map in web service. 



In order to ease the querying process, a service was designed to provide 
information about features by mouse-clicking on visible layers. A pop-up 
window appears when user clicks on a feature. This provides information 
about the i dentif i er and code of the sel ected feature (Figure 8) . 



5. Conclusion 

This paper addresses the procedure to build a spatial reference framework 
for survey camp data. ESRI ArcGIS has been utilized, to implement the 
framework, whi le ArcGI S Server is used to host the correspondi ng web ser- 
vices. 

The framework and prototype tools built are anticipated to help the stu- 
dents formalize the way they store, manage, browse and analyze survey 
camp data. On the other hand, camp organizers will beableto monitor the 
past and pi an the future survey camp mi ssi ons eff i ci entl y. 
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Figure 8. Example of a selected feature and its info- window. 
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